Author: Jesper Jørgensen
Posted: 8/13/2007 12:00:00 PM
When you build a virtual user, you create a user object with are populated with your local data, - just as when it’s read from the Sitecore data storage. But some information is also written into a traditional flat table called ClientData. This table contains user session details, and have a key which is the http session id. The table are cleaned up as a background thread with regular intervals, and only when a session has been idle for a while (e.g. more than 2 hours).
What this means is if you are using a load balanced environment, not using sticky sessions, you should share the ClientData table. This will allow Sitecore to regenerate the user object from the session id.
In rare occasions older load balancers could sometime drop the session ID, meaning that if the server does not support sticky session id’s either, you would lose the user object. While this is not a problem any longer with load balancers, it can still be solved in two ways:
Programmatically, by storing a cookie with a tolken id when you create the virtual user. The tolken, - along with an expiry date/time can then be used to recreate the user object on the secondary server.
Session server. Store all sessions on a session server.
Prev Next